
\subsection{Stamps for upload}
\subsubsection{Witness type}

There can be different implementations of postage stamps that differ in the structure and semantics of the \emph{proof of payment}. To allow for new cryptographic mechanisms to be used as they are developed, the \lstinline{witnessType} argument indicates the type of the witness used. 

Witness type $0$ stands for ECDSA witness, which is an ECDSA signature on the byte slice resulting from the concatenation of   1) preamble constant 2) chunk hash 3) batch reference 4) valid until date.% 
%
\footnote{The binary encoding of the ECDSA signature is 65 bytes resulting from the concatenation of the $r$ (32 bytes), $s$ (32 bytes) and $v$ (1 byte) parameters of the signature, in this order. The signature is calculated on the secp256k1 elliptic curve, just like the signatures of Ethereum transactions.}
%
This is the bare minimum that postage stamp contracts and clients must implement.%
%
\footnote{The ECDSA witness is the simplest and cheapest solution both in terms of gas consumed by the stamp verification contract and in terms of computational resources used off chain. Also, it does not rely on cryptographic assumptions in addition to those on which Ethereum critically relies, therefore as long as Ethereum is considered cryptographically secure, no advance in cryptorgraphy can render this witness type insecure. This is the justification for this witness type to be the only mandatory witness type to be implemented.}

Witness type $1$ refers to the RSA witness, which is an RSA signature on the same 128 bytes as above. The binary encoding of the RSA signature is of variable length, and is an Solidity ABI encoded array of the RSA signature $s$.%
%
\footnote{as defined in \emph{PKCS \#1}, \url{https://tools.ietf.org/html/rfc8017} and the RSA public key parameters $n$ (RSA modulus) and $e$ (public exponent).}

The RSA witness is specified so that blind stamping services can be implemented in a simple fashion, in order to mitigate the privacy issues arising from the ability to link chunks signed with the same private key. Even though blind ECDSA signatures also exist, their protocol requires more rounds of communication, making the implementation of such a service more complex, more error-prone and less performant. 

The inclusion of the entire public key in each RSA witness rather than storing the public key in contract state and just referencing it from the witness is justified by reducing the gas costs of interactions with the contract as well as future-proofing the design in case contract state rent is introduced in Ethereum. These considerations are more important than the brevity of postage stamps, marginally reducing the bandwith costs of uploading and forwarding stamped content.

Note that cryptographic advances can render RSA witnesses insecure without rendering Ethereum insecure, therefore RSA witnesses can be phased out in future versions of the protocol, if the security of RSA signatures gets compromised. Note, furthermore, that such blind signing services are not entirely trustless, through the damage they can incur is bounded. Trustless blind stamping services based on ZK proofs are not feasible at this stage, as the current algorithms are not sufficiently performant for the purpose, but given the rapid advances in the field, the development of suitable algorithms can be expected in the future, in which case a corresponding witness type will have to be specified in a separate SWIP.

\subsubsection{Contract Upgrades}

In order to facilitate the upgrade of the contract either in case of a discovered vulnerability or some feature extension (such as adding new witness types), it is recommended that the part holding the funds with the database of payments and the part that verifies witnesses are in separate contracts so that a backwards-compatible upgrade can be performed with minimal disruption.

In order to avoid centralized control, it is also recommended that it is the witness-verifying contract that is referenced in client configuration so that client operators can independently decide for themselves when and whether to switch to a new contract, as they become available.


Nodes participating in the same postage system are configured to reference the same contract on the same blockchain. This contract must conform to the following interface:

\begin{definition}[Postage contract]\label{def:postage}

\end{definition}


This accessor method returns \lstinline{true} if the proof embodied by \lstinline{witness} checks out for all other arguments within the claimed 
validity period, i.e. when \lstinline{block.timestamp} (the output of \lstinline{TIMESTAMP EVM} opcode) is between \lstinline{beginValidity} (inclusive) and 
\lstinline{endValidity} (exclusive). Outside of the validity period, the return value is \lstinline{undefined}.
 

\begin{definition}[Postage stamp basic types: batchID, address, witness, stamp, validity]\label{def:postage-stamp}
\begin{lstlisting}[language=buzz1]
// /postage

define type batchid as [segment size]byte  
define type address as bzz/address
define type witness as crypo/signature

// postage stamp
define type stamp  
    batchid
    address
    witness

define function valid stamp
as 
    // check validity on blockchain
    ethereum call "valid" using context contracts "postage"
        with @stamp
        
\end{lstlisting}
\end{definition}

\subsection{Postage subscriptions}\label{spec:format:subscriptions}

\subsection{Postage lottery race}\label{spec:format:race}